Conversation
- add planning section #13836
- add a few initial sections, mostly blank #13836
- updates across sections #13836
- updated displays and keybag #13836
- updated displays, keybag, layouts #13836
- update keybags and displays #13836
- layouts to layers (!) and add image #13836
- finish the layers section, also update keybag and displays #13836
There was a problem hiding this comment.
There looks to be some more work to do yet @srl295, especially in the glossary and 'going further' sections. Keep going!
|
|
||
| More information about BCP 47 language tag and full details on [how they are used in Keyman Developer](../../current-version/reference/bcp-47). | ||
|
|
||
| Now, go on to begin [planning](./planning) your LDML keyboard. |
There was a problem hiding this comment.
The glossary should be expanded to include as many of the technical terms used in LDML as possible e.g. Keybag, Displays, Layers, shift layer, Variables, Transforms, Markers, Reorders, Elements, base physical types (US, ISO), organisation of keys (QWERTY, AZERTY, QWERTZ), touch-only keyboard, gestures, long press, flick, multitap, LDML, XML, locale, (element) attribute, DTD, CLDR, repertoire, key element, keys element, (key) gap, (key) stretch, keytop, keycap, switch key, layer group, modifier, (keyboard) row, etc.
Some of these terms you could just give a short entry and a link to either an internal or external definition/description (e.g. the key element is described in keybag.md).
There was a problem hiding this comment.
I don't think that this para makes sense now that the Glossary is the final page in the Guide section. I would remove it or replace it with 'return to index'?
| Now, go on to begin [planning](./planning) your LDML keyboard. | |
| You have reached the end of the LDML keyboard authoring guide. Return to the [index](index). |
developer/ldml/guide/planning.md
Outdated
|
|
||
| ### Form and Function | ||
|
|
||
| - Will this be a hardware-only or touch-only keyboard? |
There was a problem hiding this comment.
It would be good to have links from the technical terms to entries in the glossary.
| --- | ||
| title: Variables | ||
| --- | ||
|
|
| --- | ||
| title: Transforms | ||
| --- | ||
|
|
| --- | ||
| title: Reorders | ||
| --- | ||
|
|
| --- | ||
| title: Markers | ||
| --- | ||
|
|
User Test ResultsTest specification and instructions User tests are not required |
mcdurdin
left a comment
There was a problem hiding this comment.
This is looking good, looking forward to seeing the next bits
Can you wrap .md at 80 chars -- this is what we try to do on other pages on the site.
|
Have re-embarked on review here, will do this when my brain is fresh. |
mcdurdin
left a comment
There was a problem hiding this comment.
Some really good work here. I have mostly nits!
| ## Why customize the display | ||
|
|
||
| Normally, the display of a keytop, whether in a touch environment or the | ||
| on-screen display of a hardware keyboard, simply matches the characrer output. |
There was a problem hiding this comment.
| on-screen display of a hardware keyboard, simply matches the characrer output. | |
| on-screen display of a hardware keyboard, simply matches the character output. |
| So, a key that outputs `a` will have a keytop that looks like `a`. | ||
|
|
||
| However, there are some situations where it is desirable to customize the | ||
| display of a key. This is where the [display] element is useful. This is an |
There was a problem hiding this comment.
| display of a key. This is where the [display] element is useful. This is an | |
| display of a key. This is where the [`display`] element is useful. This is an |
|
|
||
| ## displayOptions | ||
|
|
||
| The `displayOptions` has a single configurable option at present, the |
There was a problem hiding this comment.
| The `displayOptions` has a single configurable option at present, the | |
| The [`displayOptions`] element has a single configurable option at present, the |
| baseCharacter. | ||
|
|
||
| In Lao for example, it's sometimes preferred to use `x` as the base for showing | ||
| combining marks, rather than the dotted circle ◌. |
There was a problem hiding this comment.
| combining marks, rather than the dotted circle ◌. | |
| combining marks, rather than the dotted circle `◌` (U+25CC). |
| needed to successfully author an LDML Keyboard used with Keyman. | ||
|
|
||
| * [LDML Language Overview](overview) | ||
| We recommend to start with [Planning](./planning) and read these pags in order, |
There was a problem hiding this comment.
| We recommend to start with [Planning](./planning) and read these pags in order, | |
| We recommend that you start with [Planning](./planning) and read these pages in order, |
| <?xml version="1.0" encoding="UTF-8"?> | ||
| ``` | ||
|
|
||
| ### Outer `keyboard3` Element |
There was a problem hiding this comment.
| ### Outer `keyboard3` Element | |
| ### Root `keyboard3` Element |
| - What is the base physical type for hardware, such as US or ISO? | ||
| - Does the keyboard follow an existing organization of keys, such as QWERTY, | ||
| AZERTY, QWERTZ etc? | ||
| - Which width(s) will you start with for the touch layout? |
There was a problem hiding this comment.
| - Which width(s) will you start with for the touch layout? | |
| - Which device screen width(s) will you start with for the touch layout? |
| - Which characters are the most important to access? That is, those that would | ||
| be right on the keyboard or on a shift layer, versus others that might be | ||
| reached via a gesture or multiple key combination. | ||
|
|
There was a problem hiding this comment.
We could reference the DISCUS principles here? /developer/keyboards/standard
| `id` | ||
| : The … | ||
| `id` : The … |
There was a problem hiding this comment.
My guess is that this unwrapping was not intentional, throughout, for definition lists?
There was a problem hiding this comment.
unintentional, probably mis-parsing of markdown
There was a problem hiding this comment.
The vscode wrapping plugin I use (rewrap) doesn't recognize DLs and so munges my DLs like this. One slightly clumsy workaround is a blank line between dt and dd.
|
|
||
| `conformsTo` - Required | ||
| : This indicates the minimum supported version number of CLDR that this file conforms to. In other words, this file may not use features from CLDR versions after this number. This must be a whole number such as "46". See [CLDR Releases] for a current list of CLDR versions. Authors should use the _minimum_ possible number here so that the keyboard is the most widely usable. | ||
|
|
||
| `draft` - Optional | ||
| : For keyboards which are contributed to CLDR itself, this indicates the approval level of the [CLDR keyboard process]. For keyboard authors, it is best to omit this attribute or set it to `contributed`. Other possible values include `approved`, `unconfirmed`, and `provisional`. | ||
|
|
||
| `locale` - Required | ||
| : This attribute specifies the [BCP 47] tag used for the primary locale for this keyboard. The [`locales`](./locales) element can be used to specify additional locales, however, at least one locale must be specified in the `locale` attribute. | ||
| `conformsTo` - Required : This indicates the minimum supported version number |
#13836
@keymanapp-test-bot skip